home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / June 96 / Re Reading Formatted Text.3 < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  2.1 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Reading Formatted Text
  2. Sent:        6/11/96 11:20 PM
  3. Received:    6/12/96 8:31 AM
  4. From:        Jim Lloyd, jim@melongem.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. At 11:27 AM 6/11/96, Serge Froment wrote:
  9. >>As you've noticed, ODF R1 doesn't provide anything that exactly meets your
  10. >>needs. FW_CTextReader is the most appropriate ODF class for this task.  The
  11. >>idea is to create tool classes that use TextReader interfaces.  For
  12. >>example, you might write a lexical analyzer class along these lines:
  13. >
  14. >Jim:
  15. >
  16. >Thank you for your detailed answer. I ended up doing somewhat what you
  17. >said, using FW_CTextReader::PeekRunAhead to copy the text inside a
  18. >FW_CString where I can search for delimiters. Here is the code a came up
  19. >with:
  20. >
  21. > [ code snipped ]
  22. >
  23. >However, I am a bit concerned about the efficiency of such a method in the
  24. >case the clipboard contain a large text. (I was done writing the code late
  25. >last evening and I have not yet tested what happen in that case.)
  26.  
  27. Yes, efficiency might be a concern with the code you show.  Suppose you
  28. read in a couple hundred bytes (length==200), and there are no delimiters,
  29. or \r characters.  FW_CString::FindCharacter will have to make two passes
  30. through the data to determine that.  What's worse, after you call
  31. FW_CTextReader::Advance, FindCharacter will have to pass through those same
  32. two hundred characters at least one more time.  Of course, it is probable
  33. that the data you're processing is formatted into columns that are rarely
  34. if ever more than 20 characters, so your code will probably not be a
  35. noticeable bottleneck.
  36.  
  37. Your code would be better if FW_CString had a function to fine the first
  38. occurence of a character from a set of characters, but unfortunately it
  39. doesn't.  There is a wide range of text processing algorithms that it would
  40. have been nice if ODF provided, but we had to draw the line somewhere, and
  41. since these things were not directly related to building a framework for
  42. OpenDoc parts we felt it was better to not try to do too much.
  43.  
  44. Jim Lloyd
  45.  
  46.